nit: Not sure if you import or use it already but this looks like a great usecase for: errorgroup

This particular use case is handling a single request on a bidi stream and supporting cancellation, but it's certainly something we may end up with if we end up with write multiplexing.

There is the potential here that append will block waiting to add a pending write to the pending writes channel. When that happens the context below could expire returning an error from AppendRows. However this goroutine is still running and as soon as the pending channel is freed the append will in fact succeed even if an error was returned.

Furthermore this goroutine not being stopped when the caller context expires means that if append becomes slow due a full pending write channel, rapid calls to AppendRows, even with a short timeouts, could result in a very large number of gorountines left running.

Good point. I was reasoning through backend behaviors, didn't think through this scenario.

Spend some time refactoring this, as there were other correctness issues as well primarily around potential races.

Also, added a test explicitly to watch for goroutine leak.

Should this guard against the otherCtx expiring as well?

Something like

select {
    case ch <- pw:
        // We've passed ownership of the pending write to the channel.
        // It's now responsible for marking the request done, we're done
        // with the critical section.
        ms.mu.Unlock()

        // Record stats and return.
        recordStat(ms.ctx, AppendRequests, 1)
        recordStat(ms.ctx, AppendRequestBytes, int64(pw.reqSize))
        recordStat(ms.ctx, AppendRequestRows, numRows)
        return nil
  case <-otherCtx.Done():
       ms.mu.Unlock()
       return otherCtx.Err()
}

That way the call to append is guaranteed not to lock if ch is full and it is guaranteed to return within the given context timeout (within some margins).

And once calls to append are guaranteed to return within the timeout the goroutine in AppendRows could probably be removed and replaced with a synchronous call I believe.

The issue is that the select allows the writer to get out of sync processing append responses, which arrive in the same order as append requests were accepted. We use the channel for maintaining the ordering when processing the responses.

Understood. Thanks.